home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / cstd.arc / CSTD8#4 < prev    next >
Encoding:
Internet Message Format  |  1985-07-28  |  3.3 KB
  1. From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
  2.  
  3.  
  4. mod.std.c Digest            Wed,  3 Jul 85       Volume 8 : Issue   4 
  5.  
  6. Today's Topics:
  7.                        /* embedded in a comment
  8.                          the '\n' "character"
  9.                                  UTC
  10. ----------------------------------------------------------------------
  11.  
  12. Date: Wed, 3 Jul 85 12:47:18 edt
  13. From: mark@cbosgd.ATT.UUCP (Mark Horton)
  14. Subject: /* embedded in a comment
  15. To: std-c@cbosgd.UUCP
  16.  
  17. There are situations where you really want /* embedded in a comment.
  18. For example:
  19.         #define DEBUG_MAIN 1    /* debugging prints in main program */
  20. which can be portably turned off with
  21.         /* #define DEBUG_MAIN 1 /* debugging prints in main program */
  22. but this could generate a warning about an embedded /*.  (Not all
  23. compilers support #if and #ifdef is a more widely used method, so
  24. changing 1 to 0 isn't really the answer.)  Also consider where several
  25. possible values are kept around:
  26.         /* #define MAX  512     /* for the PDP-11 */
  27.         #define MAX     1024    /* for the VAX */
  28.         /* #define MAX  4096    /* for the IBM 370 */
  29. It's unreasonable to ifdef such things out.
  30.  
  31. Thus, compilers that insist on printing warnings about embedded /*
  32. in comments will be a pain to use.  This option should be switch
  33. selectable.  Perhaps it would be less painful if it only checked
  34. comments that contain newlines.
  35.  
  36. ------------------------------
  37.  
  38. Date: Wed, 3 Jul 85 12:47:18 edt
  39. From: mark@cbosgd.ATT.UUCP (Mark Horton)
  40. Subject: the '\n' "character"
  41. To: std-c@cbosgd.UUCP
  42.  
  43. The \n "character" is somewhat more of a problem.  The C language
  44. likes to pretend it's running on UNIX, and that this is handled by
  45. the operating system.  However, there are a number of portability
  46. problems caused by this notion that bytes are bytes and that newlines
  47. will be intrepreted in the tty driver or terminal.  The rest of the
  48. world (other operating systems and networks) use other conventions,
  49. such as length counts or CRLF terminated lines.
  50.  
  51. Every C compiler for another operating system has had to implement
  52. a flag to fopen where the application programmer specifies whether
  53. the file is a text file or a binary file.  For text files, \n gets
  54. turned into CRLF (or whatever the local convention is) and for binary
  55. files it gets left alone.  The new OSI networking environment will
  56. require this sort of information at the presentation layer as well,
  57. even on UNIX.
  58.  
  59. I don't have a wonderful solution to this, but a step in the right
  60. direction would be to standardize a flag to fopen which indicates
  61. that the file is (or is not, depending on the default) a text file.
  62. Otherwise, bytes should just be output bit for bit and their actions
  63. when printed should not be part of the standard.
  64.  
  65. ------------------------------
  66.  
  67. Date: 3 Jul 85 01:29:37 CDT (Wed)
  68. From: ihnp4!utzoo!lsuc!msb
  69. Subject: UTC
  70. To: utzoo!ihnp4!hou2d!osd
  71.  
  72. The correct abbreviation for Universal Coordinated Time is indeed UTC --
  73. it's a French acronym.
  74.  
  75. Mark Brader, know-it-all.
  76.  
  77. ------------------------------
  78.  
  79. End of mod.std.c Digest - Wed,  3 Jul 85 16:03:34 EDT
  80. ******************************
  81.